This invention relates to composite locking of objects and containers.
In a multi-user environment, a method of controlling access to objects is required, such that updates performed by one user are not overwritten by simultaneous updates by another user. Typically, multiple read-access is allowed but only single-user update is required. Additionally, objects are collected into numerous containers (e.g. databases). It is a requirement to take account of the lock state of the individual object and the lock state of the relevant container when requesting access.
According to one aspect of the invention there is provided a method of controlling access to objects and containers, each representing a group of objects, in a multi-user environment whereby lock states of the objects and lock states of the containers are stored in a computer system, said method comprising the steps of: accepting a request for access to an object or a container; deciding access based on the lock state for that object or container, the lock state of a container if the request is for an object contained within that container, and the lock state of objects grouped within a container if the request is for a container; and sending a message to the requester granting or denying access to said object or container. Updates performed by one user on an object or a container are not overwritten by simultaneous updates by another user. The above aspect of the invention supports units of work in a GUI session where a unit of work could be updating a single object, viewing a single object or copying or deleting a container of objects. This extends to manipulating entire voice applications which consist of many containers and other objects.
A further advantage is provided by storing the lock states for containers and lock states for objects in a common format, for instance, in the same table. A common data structure enables the same locking operations to be performed on any lock entry in the table irrespective of whether it is for an object or a container.
The lock state for a container or an object maybe stored in a record (lock table entry) in a table and the record (lock table entry) may comprise a container name field and an object name field containing string expressions. When a lock is placed on an object the object name and the container name may be stored in the lock table entry. When a lock is placed on a container the container name may be stored in the lock table entry and the object name field may be made null. In this way when a request for access to an object is made, the container for that object may be found in the record holding the name of the object and the lock state for that container found in the record for that container which has a null object name field. Similarly when a request for access to a container is made, all the lock states for objects with the same container name in their records maybe acquired.
The names are stored as strings (not pointers) to objects or containers, this allows the locking of conceptual objects, e.g. a conceptual container which has no existence in the file system. As far as the locking mechanism is concerned there is no difference between a conceptual container (such as a voice application) and a real container (such as a database); all locking operations may be performed on both types of container.
The lock state stored in the record or lock table entry is an exclusive lock, it provides the ability to work with an object or container without any interference from other user sessions, hence it is exclusive. Updates performed by a user are not over written by simultaneous updates by another user. A container or object may either be exclusively locked or not and advantageously a count value is stored for the exclusive lock state to allows multiple acquisition of lock by same user/session for GUI windows. This is useful for obtaining multiple views of the same object or performing parallel operations on the same object by the same user.
A The lock state may comprise a non-exclusive lock state associated with a user session. This allows multiple user access to an object in a controlled read-only manner so that concurrent exclusive access is prohibited.
The non-exclusive lock state may comprise a read lock. This allows another session to acquire a read lock on the same object or container but not an exclusive lock.
The non-exclusive lock state may comprise a write lock. This allows another session to acquire a write lock on the same object or container but not an exclusive lock.
More than one non-exclusive lock state may be associated with a lock entry. This provides that multiple users can acquire non-exclusive locks on a lock entry.
Multiple non-exclusive lock states may be stored in a linked list comprising linked records associated with record or lock table entry. In this way any number of sessions can acquire non-exclusive lock states for a particular object.
Each linked record may comprise a unique session id and count value for the lock. This allows multiple locks to be acquired by the same session. For example, voice segment editing and playing in the same the session; both editing and playing would require a lock and would be performed using the same session so that a single lock was involved but with an incremented use count. Storing a unique session identifier allows the identity of the session user who has initiated a non-exclusive lock to be found; this allows notification of current lock owners (readers) in the event of acquisition of a higher priority lock (e.g. a write for that object).